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Reliability-Based  Design 

Ontimiyatinn  Results 


•  The  cost  (volume)  increased  from  1 11 .4  in^  to  136.9  in^. 

•  Fatigue  life  increased  from  5.31  x  10"^  to  1.0  x  10®. 

•  The  optimization  converged  in  4  design  iterations. 

•  This  required  100  function  evaluations,  and  took  1397 
minutes  (23.3  hours)  when  run  in  serial  mode 
(benchmark). 

•  With  the  16  licenses  of  FE  solver  software  and  using 
parallel  execution  on  16  processors,  took  about  206 
minutes  (3  hours  26  minutes). 

•  This  was  a  speed-up  by  a  factor  of  6.78  over  serial 
processing. 

•  Some  inefficiencies  still  existed  in  the  code. 
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Scalability  Results 
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Legend  for  Defining  Runtimes 


•  For: 

•  PR  =  parallel  runtime  in  real  time 

•  CR  =  total  computational  runtime,  summed  up  over  the  processors 

•  I  =  total  Idle  time,  summed  up  over  the  processors 

•  np  =  number  of  processors 

•  nc  =  number  of  constraints 

•  we  have: 

•  PR  =  (CR  +  I  )/np 

•  or: 

•  PR  =  (  CR  /  nc  )  *  (  nc  /  np  )  +  I  /  np 

•  That  is, 

•  parallel  runtime  In  real  time  =  (ave.  computational  runtime  )*(  ratio  of 
constraints  to  processors  )  +  ave.  processor  idle  time 
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Trends  observed  in  pilot  runs 


•  The  following  trends  appear  significant  from  the  data: 

•  Increasing  the  number  of  licenses  decreases  the  average 
idle  time  per  processor. 

•  Increasing  the  number  of  processors  increases  the 
average  computational  runtime  per  constraint. 

•  Increasing  the  number  of  licenses  decreases  the  average 
runtime  per  constraint  (when  np<nc)  and  increases  the 
average  runtime  per  constraint  (when  np=nc.) 

•  Increasing  the  number  of  processors  decreases  the 
average  idle  time  per  processor  if  the  number  of  licenses 
is  8  and  increases  the  average  idle  time  per  processor  if 
the  number  of  licenses  is  2,  with  no  consistent  trend  when 
the  number  of  licenses  is  4. 
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Scalabiltiy  Surface 
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Many  Challenges 


•  Configuring  number  of  licenses,  processors,  constraints 

-  More  processors  than  licenses? 

-  One  processor  per  constraint? 

-  How  does  this  scale? 

•  Memory  and  I/O  problems 

-  We  had  unexplained  Scratch/Swap  memory  overutilization 

-  i/0  has  been  a  constant  issue 

-  “Supercomputer  -  (definition)  a  devise  for  transforming  a  compute 
bound  probiem  into  an  I/O  bound  problem” 

•  Cost  of  licenses 

-  We  must  get  better  ‘package’  pricing  for  massiveiy  paraiiei  runs 
from  COTS  software  suppiiers 

-  Or,  we  must  instead  use  “home-grown”  code 
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Conclusions 


•  Follow-on  project  to  start  in  August/September  time  frame 

•  More  processors  (over  100),  More  FEA  licenses  (32) 

•  Multi-component 
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